Distribution immutable

Liste de distribution immutables :

Ubuntu Core
CoreOS (jusqu'en 2019, depuis CoreOS est une distribution atomic)

Journaux liées à cette note :

Cette note fait partie de la série de notes : "J'ai étudié et testé CoreOS et je suis tombé dans un rabbit hole 🙈".

Note précédente : "2014-2018 approche alternative avec Atomic Project".

Suite au rachat de la société CoreOS par Red Hat en 2018, les projets CoreOS Container Linux et Fedora Atomic Host ont fusionné en juillet 2019 pour donner Fedora CoreOS.

D'après mon analyse, mise à part ignition, le projet Fedora CoreOS est construit sur les bases de Fedora Atomic Host et n'a gardé de CoreOS Container Linux que le nom "CoreOS".

Cette nouvelle distribution Fedora CoreOS reste atomic et immutable comme l'ancien CoreOS Container Linux, mais utilise désormais rpm-ostree et OSTree (au lieu du système dual partition A/B), et permet le package layering si nécessaire. La philosophie "100% conteneurs" reste encouragée, mais n'est plus une contrainte absolue.

Voici une chronologie sur l'histoire de CoreOS que m'a proposée Claude Sonnet 4.5 :

2013-2017: CoreOS Container Linux
           ├─ Atomic ✓ (dual partition)
           ├─ Immutable ✓
           └─ Package layering ✗

2014-2018: Fedora/RHEL Atomic Host
           ├─ Atomic ✓ (OSTree)
           ├─ Immutable ✓
           └─ Package layering ✓ (rpm-ostree)

2018:      Rachat CoreOS par Red Hat

2019+:     Fedora CoreOS (fusion des deux)
           ├─ Atomic ✓ (OSTree)
           ├─ Immutable ✓
           ├─ Package layering ✓ (possible mais découragé)
           └─ Philosophie: conteneurs first, mais flexible

Note suivante : "Quelques outils CoreOS : coreos-installer, graphe de migration et zincati".

Cette note fait partie de la série de notes : "J'ai étudié et testé CoreOS et je suis tombé dans un rabbit hole 🙈".

Note précédente : "Peu à peu depuis 2015, le terme immutable est remplacé par atomic".

Je constate que la plupart des personnes avec qui j'échange pensent qu'une distribution immutable ne permet que d'exécuter des containers Docker ou des applications Flatpak.
En réalité, grâce à la technologie libostree, il est possible d'installer des packages Fedora sur une instance Fedora CoreOS.

Voici un exemple sous Fedora CoreOS que j'ai réalisé avec le playground suivant : https://github.com/stephane-klein/atomic-os-playground.

Je commence par regarder l'état de l'OS avec rpm-ostree status :

stephane@stephane-coreos:~$ rpm-ostree status
State: idle
AutomaticUpdatesDriver: Zincati
  DriverState: active; periodically polling for updates (last checked Sat 2025-09-27 12:43:23 UTC)
Deployments:
● ostree-remote-image:fedora:docker://quay.io/fedora/fedora-coreos:stable
                   Digest: sha256:d196ab492e7cadab00e26511cdc6b49c6602b399e1b6f8c5fd174329e1ae10c1
                  Version: 42.20250901.3.0 (2025-09-14T22:45:05Z)

Je constate que la version 42.20250901.3.0 identifiée par le commit sha256:d196ab...ae10c1 est installée.
Cette version correspond au moment où j'écris cette note à la dernière release du stream stale listé sur cette page https://fedoraproject.org/coreos/release-notes?arch=x86_64&stream=stable.

Maintenant, j'utilise rpm-ostree install … pour installer neovim.

stephane@stephane-coreos:~$ sudo rpm-ostree install neovim
Checking out tree 1e5b81c... done
Enabled rpm-md repositories: fedora-cisco-openh264 updates fedora updates-archive
Updating metadata for 'fedora-cisco-openh264'... done
Updating metadata for 'updates'... done
Updating metadata for 'fedora'... done
Updating metadata for 'updates-archive'... done
Importing rpm-md... done
rpm-md repo 'fedora-cisco-openh264'; generated: 2025-03-19T16:53:39Z solvables: 6
rpm-md repo 'updates'; generated: 2025-09-27T01:07:36Z solvables: 24410
rpm-md repo 'fedora'; generated: 2025-04-09T11:06:59Z solvables: 76879
rpm-md repo 'updates-archive'; generated: 2025-09-27T01:38:59Z solvables: 44216
Resolving dependencies... done
Will download: 40 packages (121.6 MB)
Downloading from 'updates'... done
Downloading from 'fedora'... done
Importing packages... done
Checking out packages... done
Running systemd-sysusers... done
Running pre scripts... done
Running post scripts... done
Running posttrans scripts... done
Writing rpmdb... done
Writing OSTree commit... done
Staging deployment... done
Added:
  binutils-2.44-6.fc42.x86_64
  compat-lua-libs-5.1.5-28.fc42.x86_64
  ...
  neovim-0.11.4-1.fc42.x86_64
  ...
Changes queued for next boot. Run "systemctl reboot" to start a reboot

Neovim a bien été installé, mais je dois reboot pour l'utiliser. Voici ce que me dit rpm-ostree status :

stephane@stephane-coreos:~$ rpm-ostree status
State: idle
AutomaticUpdatesDriver: Zincati
  DriverState: active; periodically polling for updates (last checked Sat 2025-09-27 12:48:33 UTC)
Deployments:
  ostree-remote-image:fedora:docker://quay.io/fedora/fedora-coreos:stable
                   Digest: sha256:d196ab492e7cadab00e26511cdc6b49c6602b399e1b6f8c5fd174329e1ae10c1
                  Version: 42.20250901.3.0 (2025-09-14T22:45:05Z)
                     Diff: 40 added
          LayeredPackages: neovim

● ostree-remote-image:fedora:docker://quay.io/fedora/fedora-coreos:stable
                   Digest: sha256:d196ab492e7cadab00e26511cdc6b49c6602b399e1b6f8c5fd174329e1ae10c1
                  Version: 42.20250901.3.0 (2025-09-14T22:45:05Z)

La pastille ● m'indique la version (nommée déploiement) actuellement utilisée par l'instance.

Lors du démarrage du serveur, grub est configuré pour booter sur le premier déploiement de la liste. Exemple :

Une fois le serveur démarré, je peux voir que la version 42.20250901.3.0 est toujours utilisée, mais avec en plus un layer qui contient le package neovim :

[stephane@stephane-coreos ~]$ rpm-ostree status
rpm-ostree status
State: idle
AutomaticUpdatesDriver: Zincati
  DriverState: active; periodically polling for updates (last checked Sat 2025-09-27 13:04:36 UTC)
Deployments:
● ostree-remote-image:fedora:docker://quay.io/fedora/fedora-coreos:stable
                   Digest: sha256:d196ab492e7cadab00e26511cdc6b49c6602b399e1b6f8c5fd174329e1ae10c1
                  Version: 42.20250901.3.0 (2025-09-14T22:45:05Z)
          LayeredPackages: neovim

  ostree-remote-image:fedora:docker://quay.io/fedora/fedora-coreos:stable
                   Digest: sha256:d196ab492e7cadab00e26511cdc6b49c6602b399e1b6f8c5fd174329e1ae10c1
                  Version: 42.20250901.3.0 (2025-09-14T22:45:05Z)

Neovim est bien accessible :

[stephane@stephane-coreos ~]$ nvim --version
nvim --version
NVIM v0.11.4
Build type: RelWithDebInfo
LuaJIT 2.1.1748459687
Run "nvim -V1 -v" for more info

Avec la commande rpm-ostree apply-live il est même possible de commencer à utiliser le package sans avoir à reboot.
Cette fonctionnalité doit se limité à des petits utilitaires. Pour les composants systèmes, il est conseillé d'effectuer un reboot.

Note suivante : "Système de mise à jour d'Android, Chrome OS, MacOS et MS Windows".

Cette note fait partie de la série de notes : "J'ai étudié et testé CoreOS et je suis tombé dans un rabbit hole 🙈".

Note précédente : "En 2016, j'ai testé Fedora Atomic Host, une expérience pénible".

Après avoir étudié et testé CoreOS pendant une semaine, je réalise que la plupart des informations que j'avais entendues sur cette distribution, et plus généralement sur les immutables ou atomiques, étaient approximatives et m'ont conduit à des erreurs de compréhension.

Quelques exemples de propos que j'ai entendus de la part d'amis sur ce sujet.

En 2025 :

« Une distribution readonly ça empêchait pas mal de choses. Je n'ai pas creusé, je n'y connais rien, mais j'ai vu beaucoup de gens se plaindre. »

ou encore 2024 :

Les distributions immuables (comme feu CoreOS) garantissent une cohérence ultime. Pas de gestion de paquets, donc ni ajout ni suppression ni mises à jour possibles. Tout est gravé dans le marbre. Pour protéger le marbre, la partition racine est montée en lecture seule. Note suivante : "Ajout de packages dans des distributions atomiques". Le choix est extrême, mais l’idée est de servir de socle pour une abstraction de plus haut niveau. Imaginé pour les conteneurs, ils peuvent aussi gérer des machines virtuelles.

Pour mettre à jour, il suffit de redémarrer sur une nouvelle version. Techniquement, il y a deux partitions bootables, la courante, en lecture seule, la version suivante sur laquelle on a appliqué des patchs, soit n et n+1. Si le redémarrage de mise à jour se passe mal, rembobinage sur la dernière version connue comme stable.

Ma première erreur consistait à penser que distribution atomic et distribution immutable désignaient la même chose.

Les distributions immutables ont les caractéristiques suivantes :

Système de fichiers racine en lecture seule
Protection contre les modifications accidentelles
Peut ou non avoir des mises à jour transactionnelles

Les distributions atomics ont les caractéristiques suivantes :

Toujours immutable (par nature)
Mises à jour transactionnelles (tout ou rien)
Capacité de rollback complet
Basé sur des images système versionnées (généralement OSTree)

Les distributions atomic modernes, telles que Fedora CoreOS, Fedora Silverblue permettent en plus :

La modification de l'image de manière transactionnelle, par exemple d'installer des packages supplémentaires via rpm-ostree
Personnalisation tout en gardant les bénéfices de l'approche atomic

En 2016, lors de ma première utilisation de Fedora Atomic Host, j'avais compris que cette distribution était immutable comme CoreOS, sans réaliser qu'elle était aussi atomic. Contrairement à CoreOS qui interdisait tout ajout de packages système, Fedora Atomic Host permettait déjà via rpm-ostree d'installer des packages de manière transactionnelle (package layering), tout en conservant les bénéfices des mises à jour atomiques et du rollback.

À l'époque, CoreOS mettait l'accent sur son approche "100% conteneurs" et son immutabilité stricte, ce qui m'avait fait passer à côté de cette différence importante.

D'après ce que j'ai compris, la terminologie autour des distributions immutables et atomic a évolué au fil du temps. Si les concepts techniques sont bien définis (immutabilité du système, mises à jour transactionnelles), leur usage dans la communication a varié selon les projets et les époques. J'ai l'impression que cette ambiguïté persiste aujourd'hui.

Note suivante : "Ajout de packages dans des distributions atomiques".

Cette note fait partie de la série de notes : "J'ai étudié et testé CoreOS et je suis tombé dans un rabbit hole 🙈".

J'ai eu mon premier contact avec une distribution dite "Atomic" ou "Immutable" en 2016.

On m'avait donné accès à une instance de la distribution Fedora Atomic Host de Atomic Project (page "Introduction to Project Atomic" de 2016).

On m'avait présenté le concept ainsi : « Il s'agit d'une distribution atomic immutable où tu ne peux rien installer directement sur l'OS. L'avantage ? Un système très stable et sécurisé. L'approche est 100% centrée sur le paradigme des containers Docker. Besoin d'un outil cli ? Tu utilises un container Docker. »

L'expérience a été pénible pour moi. Par exemple, je n'avais même pas accès à vim.
Je me sentais bloqué à chaque étape.
Je comprenais l'intérêt du concept et il me séduisait théoriquement, mais en pratique, l'expérience était vraiment désagréable. Cela explique pourquoi jusqu'à cette semaine, 9 ans après, je n'ai jamais retouché à ce type de distribution tout en gardant un œil sur leurs développements.

Note suivante : "Peu à peu depuis 2015, le terme immutable est remplacé par atomic".